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7 Functional niode) of MHS 

and organizational configuraoons. 

7.1 DctatptionvftteMHSnKxUl 

» f^ view of tbc MHS model is J. "^£££LV££ ^ ^« 
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7-2 Structure of messages 

The basic structure of messages conveyed by the MTS is shown in Figure 2/F.400. A message is made op of 
an envelope and a content. The envelope carries information mat is used by the MTS when transferring the message 
within the MTS. The content is the piece of information that the originating UA wishes delivered to one or more recipient 
UAs. The MTS neither modifies or examines the content, except for conversion (see {15). 



73 Application of ihe MHS model 

7.3.1 Physical mapping 

Users access UAs for message processing purposes, for example, to create, present, or file messages. A user 
can interact with a UA via an input/output (I/O) device or process (e.g. keyboard, display, printer etc). A UA can be 
implemented as a (set of) computer proocss(es) in an intelligent terminal. 
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Intercommunication with physical delivery services 



10.1 introduction 

Th* value of message handling systems can be increased by connecting them to physical <^v«y (TO) 

idc ru 'wtm ^tu -tody Tbe capability of intercommunication between PD and MH services is an 

2!^Sl 2LS^o?lS&^L wUcS^ l^y ajjucarion socb as IPM. All users of MHS will have the ^to 

™*1esc^^ 

municatioo are defined in Annex B and cl ass i fi ed in S 19. 

a .hvsksl delivery system is a system, operated by a mwmgrmmt domain. mat transports and delivers 

and its eo closing paper envelope. 

A nbvsical delivery access unit (PDAU) converts an MH user's message to physical form, a P^f^f^J^ 1 
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Tbe capabilities in this section cover the application of security features to protect messages directly 
submitted to the message transfer system by a user agent, message store, or an access tmh. They do not cover the 
application of security features to protect comnianication between users and tbe message handling system, or MH 
user-to-MH user ctxxnmimication (a large part of MH user-to-MH user cornrmmi ration is p i oce cted between two UAs). 
Thus they do not apply, for example, to communication between a remote user's terminal and its UA, or to 
canimtnncatfton between these users* t»*««tn»l equipment and other users in the MHS. Sec urit y capabilities to protect 
MH user*to-MH user communication are for further study. 

Many of the secure messaging elements of service provide an crigmaror-to-rccipient capability, and require 
the use of user agents with security capabilities. They do not require tbe use of a message transfer system with security 
features. [As an example, content confidentiality can be applied by enciphering tbe message content by tbe originator, 
and deciphering by the recipient, with various security parameters transferred within the message envelope. Such a 
message can be transferred by any MTS which can handle the format of the content (unformatted octets), and 
transparently handle the security fields m the envelope.] 

Some of the secure messaging elements of service involve an interaction with the Message transfer system, 
and require the use of message transfer agents with security capabilities. (As an rx ampin, ooo-iepodiation of 
submission requires tbe MTA, to which tbe message is submitted, to contain mechanisms to generate a proof of 
submission field.) 

Some of the secure messaging elements of service apply to tbe MS as well as UAs and MTAs, such as 
message security in general, however, the MS is tra nsparen t to security features mat apply between the 

originators* and the recipients* s UAs. 

The scope of the secure messaging elements of service is given m Table 2/F.400. This describes the elements 
of service in terms of which the MHS component is the "provider** or the "user" of the security, service. For example, 
probe-origin authentication is provided by the originating UA, and can be used by the MTAs through which the probe 
P **«g^ An overview of these elements of service is given in ft 15.4. 

This overview describes the use of security services by the UA, MS, and the MTA. How these features are 
applied to access units is for further study. 

ISA MHS-security capabilities 

The elements of service describing the security features of MHS are defined in Annex B, and classified 
in § 19. An overview of these capabilities is as follows: 

— Message origin authentication: Enables the recipient, or any MTA through which the message passes, to 
authenticate the identity of the originator of a message. 

w . Report or igln authentication: Allows the originator to authenticate tbe origin of a delivery/ooo-dclivery * 

report. 

— Probe origin authentication: i»t*»M** any MTA through which the probe passes, to authenticate tbe 
origin of tbe probe. 

— Proof of delivery: Er a fr'rs tbe originator of a message to authenticate tbe delivered message and its 
content, and the identity of the recipient(s). 

_ Proof of submission: Enables tbe originator of a message to authenticate that the message was submitted 
to tbe MTS for delivery to the originally specified recipients). 

— Secure fic cr** management: Provides for authentication between adjacent components, and the setting 
up of tbe security context. 

— Content integrity: Enables tbe recipient to verify that the original content of a message has not been 
modified. 

— Content confidentiality: Prevents the unauthorized disclosure of the content of a message to a party 
other than the intended recipient. 

— Message flow confidentiality: Allows the originator of a message to conceal the message flow through 
MHS. 
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1 5.6 MHS-sccurtty dependencies 

If, as a result of using MHS security capabilities, there are any dependenc ie s , ctmseqoeaoes or rcstricooos oo 
other MHS capabilities (e-g. on distributxoo lists or conversion), then these shall be defined by the security policy. 

The abstract security model for message transfer is described in § 10 of Rrxomnteodarion X.4G2. in 
particular, § 10.1 of Recommendation X.402 describes the coocept of security policy. 



16 Conversion In MHS 

The MTS provides conversion functions to allow users to input m ess ag es in one or more encoded formats, 
called encoded information types OETTs). and have them delivered in other EITs to cater to users with various UA 
capabilities and terminal types. This capability is inherent in the MTS and increases the possibility of deli very by 
tailoring the message to the recipient's terminal capabilities. The ETTa standardized in MHS axe listed m Cut l 
Rcc, X.411 IISO/IBC 10021-4. Conversions and the use of the elements of service relating to conversion are available 
for EITs not defined in OCll ' l Rec X.411 I ISO/IEC 10021-4, but supported by certain domains , either bilaterally 
between these domains or within a domain itself. 

MH users have some control over the conversion process through various elements of service as described in 
Annex B. These w>iiwi#> the ability for a user to explicitly request the conversion required or as a default to let the 
MTS determine the need for conversion, and the type of conversion performed. Users also have the ability to request 
that conversion not be p erf ormed or that conversion not be performed if loss of inf ocmanoo win result. When the MTS 
performs conversion on a message, it informs the UA to whom the message is delivered that conversion took place and 
what the original ETTa were. 



17 Us« of the MHS In provision of public services 

The message handling system is used in the provision of public MH services mat are offered by 
ArfWt^ictTnTfrv^ f~ ^ Ky rti^ir «qyVrn»~* Thftgfe ptiblic MH services, are defined in the F.400-Serica of Recommen- 
dations and include: 

- the public message transfer service (Recommendation F.410); 

- the public interpersonal rp~* service (Rrcriminrndatioa P.420). 

In addition, complementary public services are offered by Admixrctratkms to aUow for the mtercom- 
murncanon between OCTTT services and the public MH services mentioned above, as follows: 

- mtercommunicauon between 1 tbcIPM service and the telex service (Recommendation F.421); — - 

- mtercommunication between the IPM service and the telctex service (Recommendation F/422); 

- u)teroommumcatiou between die IPM service and telefax services (Recommendation F.423); 

- mtercommunication whh public physical delivery services (Recommendation F.415); 

A Recommendation describing the naming and addressing aspects for public MH services exists as follows: 
_ naming and addressing for public message handling services (Recommendation F.401). 
See also Recommendations F<435 and F.440. 



18 Elements of service - Purpose 

Elements of service are particular features, functions, or capabilities of MHS. All the elements of service 
applicable for MHS are defined in Annex B. where they are listed in alphabetical order with a corresponding reference 
number. The realization of these elements of service in MHS are described in other CCTTT Recommendations in the 
X.400 series I parts of ISO/IEC 10021. 

30 Recommendation F.400 (OS/92) / 5L400 (OS/93) 



OPYRIGHT 2000 International Telecommunication Union/ ITU Telcommunication St anda rdization S 
nformation Handling Services, 2000 



Elements of «*. a* -oc^* ^^^t^Z^^^^T^f 
^^T^cf^ «vicc which provide for abasiccapatoiuy w ^^XT^vv^ for the statin* and rcoeivms of 

the mrasffg^ «nre as weu as 

-, vi. ™ mhS except those defined in Recommenda- 

Tablc 3/F.400 Us* all *e ^^tT^^^^a^^^ P—* ^ ""^SiE 
t^F.435 anoF^^^a^^ „d *v« the conxspootog 

service IPM service, and PD service, or wdcu« 7 
refcrcoce number to the definition us Annex B- 



TABLE 3/R400 



MHS 



Element* of service 



Addition pby deal icodltioo 
Alternate recipient allowed 



Antborizing neem 
AatD-for*wkdiDdic»tioo 

Anto-eu bmltted indication 
Buic physical reivnncn 
Bnnd copy recipient indication 
Body p«rt encryption ir>dic*tioo 
Content confidentiality 

Content integrity .. t 

Content type indicafioo 
CcDVOTiDD prohibitjoo 

CoBVcm^ p«*ibldan in of lo» of infa--*- 
Coa verted indicat io n 
Cottoter collection 
Counter collection with advice 
Croo-rcfattttciP* in dicati on 
Deferred delivery 
Deferred delivery caaceUatioo 
Delivery notification 
Delivery time rfaxnp indication 
Deli wry via borcauf ax service 
r>^*D*n of recipient* 
Disclosure of other jecipicott 
DL-cxpansioo hiftory indication 
DL-expans* 00 prohibited 
EMS (express mail service) 
Expiry date iiKlicatioo 
Expttrit conversion 



MT 



X 
X 



IPM 



X 
X 
X 
X 
X 
X 



X 
X 
X 
X 

X 
X 
X 
X 



X 
X 
X 

X 
X 



PD 


MS 


X 




X 








X 




X 




X 




X 

K 





reference 

B.1 
B2 
B3 

hA 

BJ 
B.6 

B.7 

B.8 

B.9 

B.10 

B.ll 

B.12* 

B.13 

B.14 

B.15 

B.16 

B.17 

B.1S 

B.19 

BJO 

B.21 

B.22 

B.23 

B.24 

B2S 

B.26 

B57 

B.28 

B.29 

B,30 



ReconunendaUonF.400 (OS/92) / X-400 (03*3) 



31 



" ■■ ■•" ■^■■ nlMBI " null. — standardization 

- . ..-^.i Telecommunication Union/ ixu ieiwHiiuvm 

COPYRIGHT 2000 Internatxonal Telecommun 
information Handling Services, 2000 



owcnnrtin *vp ?imo47A l > 



TABLE 3/F.400 (canL) 
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